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ADAPTIVE SOFTWARE INSTALLATION PROCESS SUPPORTING MULTIPLE 
LAYERS OF SECURITY-RELATED ATTRIBUTES 

FIELD OF THE INVENTION 

This invention relates to computer systems and in 
particular to improved systems, methods and apparatus for 
providing security for programs installed in computer systems. 

BACKGROUND OF THE INVENTION 

Since the start of the personal computing era in the 
late 1970s, software publishers have been concerned with 
software piracy, that is, the unlicensed copying, or 
installation, or use of software by the user. 

Most unprotected software programs can be easily 
S copied onto transportable media. Accordingly, such software 
| may be and is often installed on one or more personal computers 
lis other than the one for which the software was originally 
U licensed, without the publisher being able to recover any 
5 additional licence fees from the users of these additional 
E computers. The advent of network connections means that even 
3 the minimal requirement of transportable media is obviated. It 
^0 is understood for the purposes of this invention that the term 
"computer" includes any generally programmable processor-based 
device, including but not limited to, personal computers, video 
game consoles, Personal Digital Assistants and wireless 
devices . 

2 5 Copy protection approaches known in the art have 

represented a trade-off because the effectiveness of the 
protection generally has a direct correlation to the 
intrusiveness of the protection approach. More generally, the 
field of Digital Rights Management seek to control use of all 
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forms of digital goods and limit such use only to authorized 
users. The same tradeoffs also apply in this field. 

In the current art there are various software -only 
approaches that are minimally intrusive, but many of them are 
also only minimally effective. Such approaches often involve 
code that attempts to obtain an authentication, in the form of 
a registratidn number or a password. 

In the most simple and most easily implemented 
approaches to Digital Rights Management, authentication is 
verified at the time of installation to permit access to the 
software. Once the authentication has been verified, the 
software is forever unlocked and can be used with impunity and 
even copied to other computers, whether that of the user or 
that of another. 

For example, U.S. Patent No. 6,041,411, entitled 
"Method for defining and verifying user access rights to a 
computer information" issued March 21, 2000 to Wyatt, discloses 
a system for the secure purchase of software. The software 
cannot be executed unless the user enters an activation code 
into the computer prior to the first execution of the software. 

U.S. Patent No. 6,009,525 entitled "Multi-tier 
electronic software distribution" issued December 28, 1999 to 
Horstmann, is a slightly more complex variant. It discloses an 
incremental shrink-wrapping process in which each stage of the 
software distribution process can edit distribution rules which 
must be satisfied, before that shrink-wrapping layer will be 
unlocked. When all of the shrink-wrapping layers have been 
unlocked, the software may be installed and subsequently used 
with impunity. 
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Another example of such an approach is U.S. Patent 
No. 5,337,357 entitled ^Method of software distribution 
protection" issued August 9, 1994 to Chou et al . Random and 
unique identifiers are obtained from the hardware environment 
of the computer on which the software is to be installed and 
executed. The installation utility generates a first key that 
the user communicates to the vendor, who calculates a unique 
second key based on the first key and a decrypting key. The 
second key entered by the user into the computer is compared 
against both the first key data and the underlying identifiers 
on the computer to validate both the key and the computer prior 
to installation. 

More sophisticated software approaches are used to 
provide increased effectiveness. They cause the software to 
automatically retrieve information such as a user 
authentication from the architecture of the computer itself or 
externally, in the form of a password which was entered into 
the computer memory at an earlier point for subsequent 
reference by the program. The intrusion of the approach is 
minimized because the software automatically retrieves the 
authentication, so that the performance of the software is not 
materially impaired by the protection scheme. 

However, the open, multitasking nature of personal 
computers renders such software approaches relatively 
vulnerable to attack. Because multiple processes can operate 
concurrently, with each process having access to the entirety 
of the computer, the software putatively protected by such 
software approaches may co-exist with other software, such as a 
software debugger, which can be used to examine the actions and 
responses of the protected software. Accordingly, the control 
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mechanisms can be identified and the code of the protected 
software modified to disable the protection only. 

Such attacks can be made extremely difficult by 
appropriate design of the software protection mechanisms. For 
example, in U.S. Patent No. 5,935,246 entitled ^Electronic copy 
protection mechanism using challenge and response to prevent 
unauthorized* execution of software" issued August 10, 1999 to 
Benson, there is disclosed an electronic copy protection scheme 
using public key cryptography. The software periodically 
issues an encrypted challenge which encompasses both the public 
key adopted by the user and the private key adopted by the 
vendor, which information is contained in a keyfile generated 
by the vendor upon registration of the software from 
information provided by the user. The keyfile may contain 
hidden information concerning selective activation of services 
of the copy-protected program. 

However, such approaches cannot in principle be made 
inviolable. The modified software that results from a 
successful attack can then be circulated with impunity and used 
even by technically unsophisticated users of the software. 

Rather the approaches depend on making it so 
difficult to defeat the Digital Rights Management scheme that 
the potential gain from doing so is outweighed by the effort in 
achieving it. However in achieving this result, the software 
developer must typically expend considerable effort and expense 
co implement, such a scheme. 

An example is U.S. Patent No. 5,940,590, entitled 
^System and method for securing computer-executable program 
code using task gates" and issued August 17, 1999 to Lynne et 
al. A system of securing program code modifies the original 
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software prior to installation to introduce so-called task 
gates. These gates will control unauthorized entry to a task 
or boost the user's authority while the task is executed. The 
task gates determine, when they are encountered during 
5 execution, whether the user executing the modified software 
meets the security authorizations specified by the gate. 
Accordingly, this process consumes significant development 
resources, as the software developer must identify each task to 
be protected, the exact security authorization to be specified 
10 and insert the appropriate task gates. 

A recently popular variant of such software 
q approaches is to provide mult i -level security. For example, a 
^ software program may be sold to a user with minimal 
a g functionality at the outset, but with considerable additional 
^5 functionality installed but not immediately accessible. The 
m software purchaser may use the minimal functionality software 
^ with impunity, and even copy it, but will not be permitted to 
U access the additional functionality until an additional licence 
LH fee is paid. Upon payment of the fee, the purchaser is 
l§0 provided with a password or key that can be supplied to the 
2 software, for example by typing it into a registration window, 
thereafter unlocking some or all of the enhanced features. 
This multi- level security feature provides marketing advantages 
in terms of ability to try out software and convenience. 

25 However, the multi-level security feature is at its 

essence a software security device and subject to the class of 
attacks previously described. 



30 



There have been a number of approaches in which the 
run-time execution of a process is interrupted to obtain 
security information. Such approaches can be made effective by 
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increasing the extent of run- time intervention required by the 



For instance, the user can be prompted to provide the 
authentication at certain points in the execution of the 
5 software. Other approaches require ongoing interaction with 
and/or support by the software vendor. 



"Secure software system and related techniques" issued December 
28, 1999 to Shavit, there is disclosed a processing system 
10 which includes a code extraction processor. The code 

extraction processor parses an original software program into a 

0 first and second program/ where the first program is made 

rjj f ree iy available to the user. The second program contains a 
= F small portion of the program that is required for proper 
5s execution of the program and is installed on a dedicated server 
fU operated by the software vendor. The second program is made 

1 selectively available to the user by means of queries along a 
N communications network from the first program on the user's 

as e 

fy computer to the dedicated server on which the second program 
WO resides . 



performance of the software will be correspondingly degraded. 
Such approaches therefore are generally characterized by delay 
or slow execution, as the security investigation takes place on 
25 a number of occasions during and throughout the execution of 

the software. Eventually, the user perceives the intervention 
as a nuisance. 

Other effective protection approaches involve the use 
of hardware. Generally, the computer on which the software is 
30 to execute is required to have installed a secure, tamper- 



protection scheme. 



Por example, in U.S. Patent No. 6,009,543 entitled 



However, with such increased intervention, the 
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resistant hardware-based adjunct device. An example of this is 
the "dongle" , a piece of hardware that attaches to a personal 
computer via one of its external ports, and which is required 
in order for the software to properly function. Other examples 
5 include smart cards and cryptographic co-processor chips 
located on personal computer internal buses or peripheral 
cards . 

Such hardware security devices are effectively "on- 
off" solutions, that is, they can be used only to allow or deny 
10 the use of the software in its entirety. Multiple levels of 
functionality cannot be accommodated by a single such device* 
Rather a plurality of such devices would be required. 



intrusiveness of a different character. Rather than impacting 



FU approaches are inconvenient because of the requirement for a 
[ hardware adjunct device. The hardware components generally add 
H to the purchase price of the software and consumers are 
Hj generally unwilling to bear this additional cost, especially 
M when its sole purpose is to prevent them from doing with the 
P software what they otherwise could freely do. Moreover, the 
hardware component is a tangible and often visual reminder of 
the lack of trust that the software manufacturer has for the 
consumer of its products, with attendant marketing drawbacks. 
25 For this reason, such hardware approaches have to date obtained 
limited commercial acceptance. 

The lack of commercial acceptance of hardware adjunct 
devices has led to a " Catch- 22" situation. The manufacturers 
of personal computers will not add the capability to 
3 0 accommodate such hardware components if consumers are unwilling 



These approaches are also effective, but suffer from 



IS 



the run- time performance by requiring user input, hardware 
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to pay for it, especially since there is no direct benefit to 
the manufacturer for so doing. Sales of such devices will be 
adversely impacted if there are only a small number of 
computers that can accommodate them. Moreover, software 
5 publishers will not write software that makes use of such 
capability unless and until there is a significant base of 
personal computers having such capability. 

Nevertheless, it is anticipated that the installed 
base of computers that will accommodate and have installed such 
10 devices will gradually increase. Eventually, the installed 

base will reach a critical mass and hardware protection schemes 
will become a viable alternative. 
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SUMMARY OF THE INVENTION 

Accordingly, it would be advantageous to provide 
simple, inexpensive and efficient mechanisms for implementing 
such protection schemes into software products under 
5 de ve 1 opme n t . 

Additionally, it would be advantageous to provide 
mechanisms to retrofit such protection schemes into software 
products that are already on the market and have not yet become 
outdated without significant development effort. 

10 Accordingly, it is desirable to provide an improved 

n system for securing computer programs that is convenient, 
v3 effective and does not require material interruption of the 
2 program execution. 

=p The present invention accomplishes these aims by 

15: providing a system in which the original software is 

3 transformed into a plurality of versions/ each having a 
different level of capability. A first version with less 

fy capability than a second version contains inspection functions 

^ that identify security-related attributes of the computer on 
2m which the software is to be executed. The second version 
contains binding functions that make use of the security- 
related attributes of the computer associated with that version 
of the software . 

All of the versions are available for installation on 
25 the user's computer. As part of the startup of the first 
version, its inspection functions are invoked and if the 
security-related attributes required for the second version are 
found in the user's computer the second version is started up 
in the place of the first version. When the second version 



Dec-28-2000 1 1 :35am F r om-FE ATHE RSTON HAUGH LP +613 _ T-248 P. 016/054 F-491 

- 10 - 



• 



executes, the binding functions are invoked and the security- 
related attributes of the user's computer are invoked by the 
executable image. 

According to a broad aspect of an embodiment of the 
5 present invention, there is disclosed a processing system 
comprising: a generation processor at a first computer to 
receive an original software product and to provide a first 
version of the software having a limited functionality and a 
second version of the software having increased functionality 
10 which is dependent upon and utilizes security-related 

attributes of the computer on which the software is to be 
executed; and an execution processor at the second computer, 
adapted to receive the versions of the software from the first 
^ computer, comprising: an assessor for identifying, prior to 
l|J execution of the first version, the security-related attributes 

X of the second computer; a version initiator for initiating the 

\ y 

^ execution of the second version in the place of the first 

f version if the security-related attributes of the second 

fy computer supports the increased functionality of the second 

2g version during which the security-related attributes of the 

p second computer are utilized; and a code processor for 

^ executing the version of the software to be executed. 

According to a second broad aspect of an embodiment 
of the present invention, there is disclosed a generation 

25 processor at a first computer to receive an original software 

product and to provide a first version of the software having a 
limited functionality and second version of the software having 
increased functionality which is dependent upon and utilizes 
security-related attributes of the computer on which the 

30 program is to be executed, whereby an execution processor at 
the second computer may receive the versions of the software 
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from the first computer, identify, prior to execution of the 
first version, the security-related attributes of the second 
computer, initiate the execution of the second version in the 
place of the first version if the security-related attributes 
of the second computer supports the increased functionality of 
the second version during which the security- related attributes 
of the second computer are utilized, and execute the version of 
the software to be executed. 

According to a third broad aspect of an embodiment of 
the present invention, there is disclosed an execution 
processor at a second computer for receiving from a first 
?=4 computer, a software product for execution on the second 
Jjg computer in the form of a first version of the software having 
a limited functionality and a second version of the software 
^■fb having increased functionality which is dependent upon and 
± utilizes security- related attributes of the computer on which 
.il the program is to be executed, the execution processor 
=^ comprising: an assessor for identifying, prior to execution of 
fu the first version, the security-related attributes of the 
2lU second computer; a version initiator for initiating the 
□ execution of the second version in the place of the first 
u version if the security- related attributes of the second 

computer supports the increased functionality of the second 
version during which the security-related attributes of the 

2 5 second computer are utilized; and a code processor for 

executing the version of the software to be executed. 

According to a fourth broad aspect of an embodiment 
of the present invention, there is disclosed a method of 
selectively controlling the functionality of a software 

3 0 product, the method comprising the steps of: generating, at a 

first computer, a first version of the software having a 
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limited functionality and a second version of the software 
having increased functionality which is dependent upon and 
utilizes security-related attributes of the computer on which 
the program is to be executed; receiving the versions of the 
5 software from the first computer, at a second computer for 

execution thereon; identifying, prior to execution of the first 
version, the security-related attributes of the second 
computer; initiating the execution of the second version in the 
place of the first version if the security-related attributes 
10 of the second computer supports the increased functionality of 
the second version during which the security- related attributes 
of the second computer are utilized; and executing the version 
□ of the software to be executed. 

p According to a fifth broad aspect of an embodiment of 

15J3 the present invention, there is disclosed a computer -readable 
In medium for storing computer-executable instructions which, when 
§4 executed by a processor in a first computer, cause the 
L P r °cessor to: receive an original software product and to 
fU provide a first version of the software having a limited 
2§z functionality and a second version of the software having 
p increased functionality which is dependent upon and utilizes 
^ security-related attributes of the computer on which the 

program is to be executed, whereby an execution processor at 
the second computer may receive the versions of the software 
25 from the first computer, identify, prior to execution of the 
first version, the security-related attributes of the second 
computer, initiate the execution of the second version in the 
place of the first version if the security-related attributes 
of the second computer supports the increased functionality of 
30 the second version during which the security-related attributes 
of the second computer are utilized and execute the version of 
the software to be executed. 
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According to a sixth broad aspect of an embodiment of 



the present invention, there is disclosed a computer- readable 
medium for storing computer-executable instructions which, when 
executed by a processor in a second computer, cause the 
5 processor to: receive from a first computer/ a software product 
for execution on the second computer in the form of a first 
version of the software having a limited functionality and a 
second version of the program having increased functionality 
which is dependent upon and utilizes security-related 
10 attributes of the computer on which the program is to be 

executed, identify, prior to execution of the first version, 
the security- related attributes of the second computer; 
Q initiate the execution of the second version in the place of 
H the first version if the security-related attributes of the 
£5 second computer supports the increased functionality of the 
*» second version during which the security-related attributes of 
fU the second computer are utilized; and execute the version of 
1 the software to be executed. 

ft- BRIEF DESCRIPTION OF THE DRAWINGS 

|K) The embodiments of the present invention will now be 

rj described by reference to the following figures, in which 

identical reference numerals in different figures indicate 

identical elements and in which: 

Figure 1 is a diagrammatic representation of the 
25 interplay between versions of the software generated by the 
embodiment of Figure 1; 



Figure 2 is a block diagram of a hardware environment 
in which the embodiment of Figure 1 will operate; 
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Figure 3 is a diagrammatic representation of an 
embodiment of the present invention; 



Figure 4 is an example of a metadata file used in the 
embodiment of Figure 1; and 



5 



Figure 5 is a flow chart showing the execution 



processing of the embodiment of Figure 1. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring now to Figure 1, there is shown a 
diagrammatic representation of the interplay between versions 

10 of a software product generated by an embodiment of the present 
invention, 

*p In software suitable for application of the present 

invention, functionality can be allocated among a plurality of 
f|J versions of software 110, 120, 130, 140 of respectively 

11 increasing capability. Higher capability versions will make 

H use of some security-related attribute of the computer in which 
the versions are installed for execution. 



" embodied in hardware, although it is possible that some may be 
20 embodied in software. Typical hardware security-related 

attributes may include adjunct devices, whether or not tamper 
resistant, including cryptographic co-processors that contain 
cryptographic keys in protected storage, dongles attached to 
external ports that contain cryptographic capabilities, or 
25 smart -cards and smart -card readers. 



Such security-related attributes are primarily 



However, security-related attributes need not be 
security-specific. Indeed the attribute may be nothing more 
than the presence or absence of a hard drive, an internet 
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connection, an authenticable security capability on a network 
coupled to the computer, a user certificate such as an X.509 
certificate or an independent authentication for user 
identification. 

Software attributes , such as the presence of a run- 
time debugger (suggesting an attempt at bypassing security 
efforts) or evidence of the purchase of an upgrade of the 
software may be considered. 

Indeed, the presence or absence of virtually any 
hardware or software attribute of the environment in which the 
computer may execute programs may qualify as a security-related 
attribute for the purposes of the present invention. 

The sole requirement is that the software product 
must be capable of determining if the attribute is present on 
the computer on which the software product is to execute and if 
so, using the attribute during execution. 

A plurality of security-related attributes may be 
considered together to compute a figure of merit. 

For simplicity, and by way of example, we will 
consider a single -player game program that executes on a 
personal computer using a Microsoft Windows™ operating system. 
The game program, which has already been developed, is 
available in three versions. 

The first version 110 is to be made available freely, 
and operates as a Memo" version of the game. As such, while 
it is unrestricted in distribution and use, it is severely 
limited in functionality, for example, only one game level is 
accessible and the game engine is of a basic variety. 
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The second version 120 makes available additional 



game levels but makes use of the same game engine as in the 
first version 110. The publisher wishes to make the second 
version 12 0 available free of charge to users who possess a 
5 certain class of smart -card reader and a suitably encoded 

smart-card which will authenticably identify the user. Thus, 
the second version 12 0 is made available to users in return for 
obtaining personal information about the user, which can be 
used for targeted marketing purposes. 

10 The third version 130 makes available still more game 

levels than the second version 120, and incorporates an 
q enhanced game engine to replace the basic game engine of the 
first version 110 and second version 120. The third version 
£ 130 will be only made available to users with access to the 
%M second version 120 who are willing to purchase the increased 
?jj capability of the third version 13 0 via an internet e-cash 
H transaction. 



m Thus, in the exemplary embodiment of Figure 1, only 

fU versions 110, 120 and 130 will be created. Accordingly/ 

version 140, which is discussed later, is shown in dotted 
□ outline together with other related elements. 



readily recognize that the present invention can be 
incorporated into any number of types and versions of software 
25 application. The minimum requirement is that the software 
application must have at lease two versions of varying 
functionality ill, 121, 131, 141 or be capable of being so 
divided. Further, the version or versions having increased 
functionality 121, 13 1, 141 make use of one or more of the 



Persons having ordinary skill in this art will 
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security-related attributes of the computer on which the 
software product is to execute. 

Referring now to Figure 2, there is shown a block 
diagram of a hardware environment in which the embodiment of 
5 Figure 1 will operate- The hardware environment comprises a 
development PC 200 and an execution PC 250, interconnected by 
internet network 240. 

The development PC 200 is the environment on which 
the versions 110, 120, 130, 140 of the software product will be 
10 generated. The versions 110, 120, 130, 140 may be generated 
after the completion of the development of the original 
^ software, as in the exemplary embodiment described above. In 
%j such a case, the development PC 2 00 need only have sufficient 
a j; capability to execute the conversion processing software 
l|J described below. 

- M Alternatively, the versions 110, 12 0, 13 0, 140 may be 

generated in the course of development of the original 
software. In this case, the development PC 200 must have 
rg sufficient capability to support the software development 
2fig process in its entirety, in addition to the capability required 
to execute the conversion software processing. 

The execution PC 250 is the environment in which the 
versions 110, 120, 130, 140 will execute. Accordingly, the 
execution PC 250 must have sufficient capability to support the 
2 5 processing of the software product, including, if appropriate, 
some or all of the security-related attributes associated with 
the higher capability versions 120, 130, 140 of the software. 



In Figure 2, the security-related attributes include 
a smart-card reader 280. The smart-card reader 280 accepts a 
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smart-card 285 containing processing capabilities. When 
inserted into the smart -card reader 2 80, the smart -card 285 
makes available an authenticated user identification to the 
execution PC 250 which can be used by software processes 
5 executing on it. 

The internet 240 is a network of network processors 
(not shown) which are inter-linked and provide a number of 
communications pathways through the network for appropriation 
on a shared basis by processors connected by a communi cat ions 
10 link to one of the network processors. 

The development PC 200 is connected to the internet 
U 240 by a broadband internet connection 241 and the execution 

processor 2 50 is similarly connected to the internet 240 by a 
=F broadband internet connection 242. 

^jfj A plurality of web sites including web site 243 are 

K conceptually shown within internet 240. In fact/ they are 
U installed on processors (not shown) for access by users of the 
fU internet 240. Web-site 243 is operated by the software 
^~ developer and is updated from development PC 200. 
13 

The software developer uses web-site 243 to download 
the versions 110, 12 0, 13 0, 14 0 of the software product to 
users such as the one associated with execution PC 250 . Those 
of ordinary skill in this art will readily recognize that there 
are other mechanisms for transfer of the versions 110, 120, 
25 13 0, 14 0 of the software product to users, including 

distribution of a transportable media such as CD-ROM or a 
diskette or along a local area network (not shown) . 



In the exemplary embodiment discussed above, web-site 
243 also provides a mechanism to permit the e-cash transaction 
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required to permit access to the third version 13 0 of the 
software product . 

Turning now to Figure 3/ there is shown a diagrammatic 
representation of the processing involved in the present 
5 invention. The elements concerned with producing the 

multilevel application are shown to the left of the dotted 
vertical line occur at the development PC 200, while the multi- 
level applications themselves and the processes involved in 
their use are shown to the right, at the execution PC 250. 
10 Boxes 310, 32 0 and 33 0 represent respectively, the executable 
images for the first, second and third versions respectively. 
fS% They are shown overlaying the dotted vertical line to denote 
y3 that they are created at the development PC 2 00 and are 
; 2 transported for installation onto the execution PC 250 as 
ij discussed above, 

!t| In the exemplary embodiment, the software versions 

s have already been developed and are shown as a core 
^ functionality 300 and additional files 304-307. The core 
fy functionality 3 00 generally comprises an executable image 
^1 ( . EXE) 301, a series of dynamic link libraries (DLLs) 302 to 
£3 perform certain basic functions and other miscellaneous files 
303. In addition, there are graphics files for each of the 
versions, 3 04-306 and an executable image comprising the 
enhanced game engine 307 to be used for the third version. 

25 The implementation of the exemplary embodiment 

comprises the application of a conversion process at the 
development PC 200 on the existing software application 300-307 
to create a corresponding set of executable files 310, 320, 330 
for installation on the execution PC 250. The (in this case 

30 three) sets of executable files 310, 320, 330 may have 
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considerable overlap between the. but are "-dually 
different and all are installed on the execut.cn PC 250. 

'tt. conversion process performed at the development 
PC 200 involves injecting two types of functions into the 
executable files corresponding to the software versions to be 
converted, inspection functions denoted 3 enerally as 308 and 
binding functions denoted generally as 309. 

in the exemplary embodiment discussed above, the 
inspection functions 308 and the binding functions 309 are 
implemented in a DLL library 3*0 that mediates the behave of 
the executable images. 

The specific dependencies that will be enforced in a 
particular set of executable files are established by files of 
metadata which specify which inspection and/or binding 
functions should be executed. An exemplary metadata fUe 
showing the specification of inspection files is shown in 
Figure 4 . 

The executable image corresponding to the three 
versions of the software 110. 120, 130, will result from 
linking the DLL library 390 to the corresponding executable 
files 310, 320, 330 at the start of execution. Those having 
ordinary skill in this art will readily recognize that this is 
not the only configuration to permit the injection of such 
functions and such a mechanism is for exemplary purposes only. 

The advantage of using DLL files for the inspection 
308 and binding functions 309 is the ease in which additional 
versions of software capability can be added. The developer 
must only define additional inspection 132 and binding 
functions 145 (shown in dotted outline in Figure 1) , create the 
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required version-specific functionality 141 and modify the 
metadata files. The existing executable files 310, 320, 330 
would be left undisturbed. 

The executable files use the inspection functions 308 
S injected into them to detect the presence or absence of one or 
more security-related attributes on the execution processor 
250. 

Thus, in the present example, the executable files 
corresponding to the first 310 and second versions 320 of the 
10 software will invoke inspection functions 112 to detect the 
presence or absence of a smart -card reader 280 of a certain 

5 type. In addition, the executable file for the second version 
% i of the software 32 0, will invoke inspection functions 122 to 

%S detect the presence or absence of an internet e-cash 

6 capability. On the other hand, the executable file 

U corresponding to the third version of the software 330 will not 
f. invoke any inspection functions because there is no version of 
fy the software with any greater capability. 

CO The executable files use the binding functions 309 

i|0 injected into them to use the security-related attributes found 
on the execution processor 250 by the inspection functions 3 08 
for the immediately lower version of the software. When the 
executable image 340, 350, 360 of the version to be run is 
starting up, it invokes the appropriate binding function 309. 
25 The binding function 3 09 ensures that the executable image can 
only be executed on a properly qualified computer environment. 
Because the finding function 309 is only invoked during 
startup, there is no material delay in the execution 
performance of the software version. 
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It will be readily recognized chat the binding 
functions 3 09 may also be invoked during the execution of the 
executable image 340, 350, 360 as required by the software 
developer, but with the recognition that to do so risks a 
material degradation in the execution performance of the 
software version. 

Thus, in the present example, the executable file for 
the second version of the software 320 will use binding 
functions 125 to intercept certain file read operations and to 
decrypt certain files using the smart-card 185 during the 
startup of the executable image corresponding to this version. 
£3 This has the effect of restricting the present instance of the 
program to execution only on the specific computer, or, absent 
J other bindings, only on a computer with the specific smart-card 
|fe present . 

V° Such intervention is well known in the art. In this 

example, it can be accomplished by means of a Virtual Device 
m Driver (VxD) which hooks file read operations and deals with 
5 the smart -card interface to provide any required decryption. 

Similarly, the executable file for the third version 
of the software 330 will use binding functions 135 to intercept 
file read operations and decrypt certain additional files using 
a decryption key provided upon completion of the e-cash 
transaction during the startup of the executable image 
25 corresponding to this version. The decryption key may have 
been stored upon receipt on the smart-card 185. 

Those having ordinary skill in this art will readily 
recognize that the inspection functions 308 and/ or binding 
functions 3 09 may result in modification of the system-level 
30 behavior of the software, whether by modification of the file 
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input /output resources, user-machine interface, or operating 
system resources, including the use of proxies. 

Once the conversion process has been completed and 
the executable files 310, 320, 330 and the DLL library 390 have 
5 been generated, these files are downloaded and installed on the 
execution processor 250. This may take place by conventional 
means with which users are already familiar, for example, by 
HTTP file transfer from the web-site 243 of a self -exploding 
installation file. It is also possible, in order to increase 
10 the security of the overall system, to defer the completion of 

the installation of higher levels dependent upon relevant 
G security attributes. For example, the distribution files for 
5 the second level might be encrypted in such a way that they 
=P require decryption by security hardware before installation. 
^5 In this manner, the higher levels are not available for 
fU malicious inspection such as disassembly, except to known 
^ users . 

fy Figure 5 is a flow chart showing the logical 

2 processing which occurs at the execution processor 250 to 
S32 0 execute the software product. The start of the execution 
W process 500 is signaled by a double click on an icon 

representing the executable file for the first version 310 in a 
manner well-known to users of computer graphical user 
interfaces . 

25 The executable file for the first version 310 begins 

loading 505. Under the Windows" 4 operating system, the loader 
loads DLLs specified in the header of the executable file so 
invoked and also runs the "load-time" code, if any, present in 
each specified DLL, before loading the core program itself. 
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The DLL library 390 is specified in executable file 
310 and accordingly is loaded by the loader. The load- time 
code of the DLL library 3 90 reads the appropriate metadata from 
a file to first determine whether there are inspection 
5 functions 308 to execute 510; The metadata also specifies 

which binding functions 3 09 to execute, but these are executed 
after any inspection functions. 

The appropriate inspection functions (in this case, 
112) are executed 52 0. The inspection functions are 

10 independent executable files which run under control of the DLL 
library 390. Inspection function 112 determines that smart - 

p card 185 is loaded in smart-card reader 180. 

'•4 The inspection function 112 may optionally query the 

In user to secure permission to load the next (second) version 
lis 530. If so, the DLL library 390 spawns a separate process to 
[I load 505 the executable file for the second version 3 20 and the 
- process corresponding to the execution of the first version 
fjMj will be allowed to die. 

10 Similar processing will now take place during the 

Jio load of the executable file for the second version 320 with the 
result that the inspection functions 122 will be executed which 
confirms that the execution processor 250 has e-cash 
capability. 

The e-cash capability could be demonstrated, for 
25 instance by asking the smart-card 185 to decrypt a token 
message encrypted by a public key of a particular e-cash 
system, which would only succeed if the smart -card 185 
contained a corresponding private key indicating membership in 
an e-cash program. 
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Note that decisions about making the next levels 
available such as were earlier described need not be performed 
in an entirely local manner, and may involve user interaction 
as long as the authorization resulting therefrom is 
5 authenticable . For example, the metadata for a particular 
level transition could specify a Universal Resource Locator 
(URL) of an internet -based transaction processor to which the 
user would be directed via a World Wide Web browser. The web- 
resident criteria for authorization could be arbitrary and 
10 return, for example, a success code in the form of a token 
which would be authenticated by a local smart -card. 

n Note that the executable files for the second 120 and 

third versions 130 have already been installed, whether or not 
_g the e-cash transaction has already taken place. The inspection 
^Is function 122 therefore is configured to also check a robust 
m success indicator, to determine if the e-cash transaction has 
^ already taken place. If not, the inspection function 122 
offers the user the opportunity to purchase the enhanced 

r 

software (either periodically or upon each invocation of the 

fi I 

f^O software) . If the user agrees to do so and the transaction is 
O completed, the robust success indicator is modified and the 
%a * third version executable file 13 0 is loaded. The robust 

success indicator can thereafter easily be checked without any 

further input from the user. 

25 When the executable file for the third version is 

loaded 33 0 and the DLL library 3 90 invoked, the metadata file 
indicates that there are no inspection functions to be 
executed, but that there are binding functions 13 3 to be 
executed. These binding functions 133 are executed, and upon 

30 completion, the executable file for the third version 330 is 
executed 550, 
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If the execution processor 250 did not have either e- 
cash capability or a smart-card capability, then the 
corresponding inspection functions 112, 122 would fail and any 
binding functions for the present version would execute 545, 
5 followed by the executable file for that version 550, 

Apparatus of the invention can be implemented in a 
computer program product tangibly embodied in a machine - 
readable storage device for execution by a programmable 
processor; and methods actions can be performed by a 
10 programmable processor executing a program of instructions to 
perform functions of the invention by operating on input data 
m and generating output. The invention can be implemented 
*R advantageously in one or more computer programs that are 
.£ executable on a programmable system including at least one 
^§5 input device, and at least one output device. Each computer 
m program can be implemented in a high-level procedural or object 
^ oriented programming language; or in assembly or machine 
u language if desired; and in any case, the language can be a 
[U compiled or interpreted language. Suitable processors include, 

rs £ 

klo by way of example, both general and specific microprocessors. 

O Generally, a processor will receive instructions and data from 
a read-only memory and/or a random access memory. Generally, a 
computer will include one or more mass storage devices for 
storing data files; such devices include magnetic disks, such 
25 as internal hard disks and removable disks; magneto-optical 
disks; and optical disks. Storage devices suitable for 
tangibly embodying computer program instructions and data 
include all forms of non-volatile memory, including by way of 
example semiconductor memory devices, such as EPROM, EEPROM, 
30 and flash memory devices; magnetic disks such as internal hard 
disks and removable disks; magneto- optical disks; and CD-ROM 
disks. Any of the foregoing can be supplemented by, or 
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incorporated in ASICs (application-specific integrated 
circuits) . 

Examples of such types of computers are programmable 
processing systems contained in the development PC 20 0 and the 
execution PC 250 shown in Fig. 1 suitable for implementing or 
performing the apparatus or methods of the invention. The 
system may comprise a processor, a random access memory, a hard 
drive controller, and an input/output controller coupled by a 
processor bus . 

It will be apparent to those skilled in this art that 
various modifications and variations may be made to the 
embodiments disclosed herein, consistent with the present 
invention, without departing from the spirit and scope of the 
present invention. 

For example, the processing on the execution 
processor 250 has been described in the context of a Windows™ 
application. Those of ordinary skill in this art will readily 
recognize that similar processing can be accomplished in 
operating systems other than Windows™. 

Further, as indicated above, once the executable file 
for a version commenced execution, the binding functions would 
have already been executed, and the executable file could run 
without interference, or at the option of the software 
developer, execute further binding functions during the course 
of execution. 

Moreover, if the load-time processing of the second 
and higher versions is time consuming, the lower version 
process may be permitted to proceed to execution while the load 
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of the higher version takes place, to be terminated upon 
commencement of execution of the higher version. 

Those persons of ordinary skill in the art will also 
recognize that it is not essential that executable files 
corresponding to all of the versions of the software be loaded 
and installed at once. 

Optionally, only the executable file for the first 
version 310 need be loaded and installed. In this case, the 
inspection function 112 could confirm that there is smart-card 
capability and monitor a robust success indicator to determine 
whether the executable file for the second version has been 
previously downloaded and installed. If not, the user may 
optionally be given the choice to effect the download, or the 
download may take place automatically. 



fits The download may use, as a security measure, a URL 

mfA from which the executable file may be downloaded. An encrypted 
U version of the URL may be stored in the metadata file which is 

decrypted by the smart-card 185. For added security, the 
m metadata corresponding to the second or higher versions may 
Jlo itself be encrypted. For still more security, the URL could be 

different for different users. 

Similar processing could be applied to download the 
executable file for the third version 330 upon the first 
invocation of the executable file for the second version 320. 

25 Other embodiments consistent with the present 

invention will become apparent from consideration of the 
specification and the practice of the invention disclosed 
therein. 
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Accordingly, the specification and the embodiments 
are to be considered exemplary only, with a true scope and 
spirit of the invention being disclosed by the following 
claims . 



